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Arpanet Users Interest Working Group Meeting 


A new group, the Arpanet Users Interest Working Group (USING) is the 
outgrowth of a meeting held in Boston on May 22-23, 1973. The 
meeting, cochaired by Dave Crocker, UCLA-NMC, and Nancy Neigus, BBN, 
followed BBN’s Resource Sharing Workshop. 


PURPOSE 


The USING meeting was seen by the members as a forum for Network 
Users to air complaints, exchange information, voice desires, and 
present concrete proposals for the design and implementation of 
user-oriented Network capabilities. 


The group will devote itself to lobbying on behalf of user interests, 
to promoting and facilitating resource sharing, to improving user 
interfaces (support), and to studies of standardization. The 
ultimate goal will be provide users identification of, and 
facilitated access to, whatever resources on the Network they might 
wish to use. 


Neigus, Crocker, and Iseli of MITRE were selected to define the 
objectives and goals of USING in more detail, and they will present 
their discussion in a later publication. 


ATTENDEES 


Dave Crocker, UCLA-NMC, Co-Chairperson 
Nancy Neigus, BBN, Co-Chairperson 

Ken Bowles, UCSD-CC 

Frank Brignoli, NSRDC 

Jim Calvin, CASE-10 

Jake Feinler, NIC 
Wayne Hathaway, NASA-AMES 
Jean Iseli, MITRE 
Mike Kudlick, NIC 
Mike Padlipsky, MIT-MULTICS 
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Lee Richardson, USC-ISI 
Ron Stoughton, UCSB 
Jim White, NIC 

Steve Wolf, UCLA-CCN 
Joe Wyatt, Harvard 


CATEGORIES OF CONCERN 


The meeting began by attempting to create a relatively complete list 
of topics directly relevant to users. The intention was to then 
discuss some of these categories in detail. The categories of 
concern to users are listed here along with a brief outline of the 
discussion and recommendations associated with each category. Not 
all topics were discussed fully due to time limitations. It was 
acknowledged that some of the recommendations were quite extensive, 
but that they should be mentioned even though their implementation 
would be far off. 


1. Online and Offline Documentation, Information Sharing, and 
Consulting 


a. There is a general need to upgrade the quality, technical 
accuracy, timeliness, dissemination, and format of both online 
and offline documentation. 


b. Documentation should avoid "buzz" words (jargon), and should 
follow easily understood syntax conventions, abbreviation 
standards, reference citation rules, etc. However, there 
probably cannot be a standard format for writing documentation. 


c. Offline documentation should be well indexed, should contain a 
good table-of-contents, and should be written in an easily 
browsable format. Online documentation should be presented in 
a browse mode with well-labeled categories of information as 
well as a keyword search capability. 


d. Documentation should be identified with date/author/version 
information, particularly in large online documents, so that it 
is easier to keep the most current version of a document and to 
query the author, in the event of problems with the 
documentation. 


e. Network news needs to be gathered and intelligently distributed 
to users (Network PR). 


f. Users need several levels and styles of access to 
documentation, whether online or offline, based upon their 
experience, interests, and preferences. 
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Each server site should also provide some degree of information 
variety in online "help" mechanisms, tailored to fit the needs 
and experience of different user types. 


In addition, entering "Help" from the EXEC level of a system 
should direct a user to ALL procedural-type information. 


New users should be carefully introduced to the Network by way 
of a New Users Packet (NUP). Since the MITRE-TIP group is the 
official contact for new users, they should design such a 
packet and incorporate suggestions from USING. 


This packet should eventually contain, among other things: 
a definition of, and introduction to the Network 
a list of sites 


step-by-step scenarios for accessing functional documents an 
related online items 


a definition of who can get on the Network 


some quick-reference charts showing a list of Network 
services available to new users 


and an introduction to Network groups, including USING, as 
well as the names of Network consultants, assistants, and 
the like. 


Information-accessing mechanisms should be provided for users, 
including interactive tutorials, user scenarios, and other 
training mechanisms. 


A Network-wide "who, what, where and when" information system 
should be implemented. (This was nicknamed the Network Yellow 
Pages.) Discussion of support for such a system focused on 
obtaining some form of central funding. 


The concept of ‘Regional Agents’ for collecting information for 
the Resource Notebook was discussed. 


Several felt that what was really needed was a ‘rebirth’ of the 
original concept of Technical Liaison as the person who 
provides information to the NIC and technical assistance to 
users. 
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There was concern voiced about the number of people collecting 
information and the redundancy of the requests received by 
sites. 


There was also concern about what incentives there are (or 
should be or can be) for Liaisons to perform their tasks 
adequately by providing truly up-to-date and complete 
information (carrot vs. stick). 


1. Server Sites should provide a variety of consulting services to 
supplement ‘help’ and general information services. 
Consultants could represent the whole Network, a group of 
sites, a single site, general areas such as software, or 
specific applications processes. This could fit into the 
workings of the Network Servers Group. 


2. Standardization for the User 


a. If they so desire, users should only have to learn one 
Executive (command) language, rather than 20. Rather than have 
every site change its interface to the user, it was suggested 
that there be a Network Common Command Language Protocol which 
is translated to/from the host’s own Executive command 
language. 


As with FTP and RJE, a human user should be able to type in CCL 
Protocol directly, though many sites may want to allow a local 
user to type in their local Executive language, and then they 
will translate it into CCLP, for the foreign host. 


Any Network Common Command Language should be compatible with 
batch systems as well as with interactive systems, and should 
provide an effective means for batch job submission and 
control. 


Bowles, Hathaway, and Stoughton volunteered to outline specs 
for Network command language that would be compatible with 
ideas suggested by Padlipsky and discussed at the meeting. 


b. One of the functions to included in a Common Command Language 
is a simple editor, which Padlipsky has outlined. The editor 
should be easy for users to learn as well as for servers to 
implement or interface to their own editors. 
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3. Status/Measurement of Site Performance 


a. 


A variety of performance measures, for the individual sites, 
needs to be derived, acquired, maintained, and made available 
to users. 


This could include some attempt to measure average "response 
time", relative costs (relative to type of task, that is), 
availability/reliability, etc. 


Mechanisms are needed for software certification and for 
measuring and verifying the accuracy and/or reliability of 
systems, hardware, protocols, applications software, etc. 


4. User Feedback Mechanisms 


a. 


Crocker, 


There is a need for a uniform Network gripe/suggestion 
mechanism. This should cover several types of gripes, 
including program bugs and service complaints. 


Each user registering a complaint deserves immediate 
acknowledgement and some indication of what, if any, action 
will be taken. 


The NIC should set up Network ident groups for Principal 
Investigators, Liaisons, Station Agents, Accounts 
Administrators, Consultants, etc., so that users can easily 
direct their comments, inquiries and mail to these groups. 


A Network Servers Group should be started, to coordinate the 
activities (to the extent possible) of the servers (a Server’s 
Cartel?). It would also provide a focus for user complaints 
and suggestions. 


(The group was originally dubbed the "Tobacco Institute". The 
Tobacco Institute acts as a representative for the disparate 
Tobacco companies, and attempts to convince the public that 
smoking is good for them.) 


The point of the Servers Group -- rather than trying to 
convince the Network public that servers are good for them -- 
would be for servers to help each other with common tasks (such 
as documentation) that are too big for each to handle alone. 


This eventually works in the users interest, because the 


servers (in the Network free-market economy) are dependent 
upon the users for their livelihood. 
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There should be cooperation between the Server Group and USING, 
but the groups would NOT be comprised of the same people. They 
are on opposite sides of the product. 


Station Agents should supply users with information of a 
clerical nature such as names, phone numbers, titles, 
documentations, etc. To be able to do this, the Agents must 
first HAVE this information. 


5. Messages to Users 


a. 


Messages to users, such as error messages or diagnostics, 
should be simple, clear, and meaningful to users. 


The user should have the ability to control notifications given 
to him, by being able to queue messages or refuse them. 


Users should be able to suppress diagnostics or to specify 
abbreviated or expanded versions. 


6. Tailoring of Resources for Users 


a. 


Interfaces to users should support different levels of user 
proficiency, without being a burden to the more proficient 
user. 


That is, a new user needs more prompting, etc. A more 
experienced user does not need and DOES NOT WANT such 
prompting. So the capabilities of the interface, which are not 
needed by a specific user, should be transparent. 


A method for work flow management that permits a user to set up 
a sequence of computer tasks that are contingent upon one 
another is needed. The user should be able to describe this 
sequence interactively and then be able to detach and continue 
with other work while the sequence of tasks is being carried 
out. 


7. Personal Information Management System 


a. 


Crocker, 


Users need a system for managing all types of machine-based 
contacts such as mail, links, journal items, etc. 


Such a system should ‘log’ what has been received and allow the 
user to keep a copy, if desired. 


It should also provide the user with options for organizing his 
personal information. 
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A personal ‘calendar’ or reminder system would be handy, 
especially if it allowed one to look ahead to coming events as 
well as to check events for the current day or week. 


A ‘return to sender’ feature is needed in the Network-wide mail 
address system. 


(Discussion of the current work on the Mail Protocol indicated 
that some of these ideas are already being considered) 


8. Uniform Accounting Procedures and Online Status of Accounts 


a. 


This topic was covered in detail by sections of the Resource 
Sharing Workshop. It is mentioned here only because it is a 
problem of real concern to users. 


9. Trial Usage and Browsing 


a. 


10. 


LEs 


Crocker, 


Ideally, users should be allowed some ‘free’ sampling of 
systems and features available at each site. Practically, this 
presents problems of space allocation, accounting, consulting, 
etc. Although none of these problems are easy to solve 
equitably, an attempt should still be made to provide some free 
usage to everyone. 

Several types of trial usage should be considered, such as for 
those who will make an immediate commitment and those who wish 
merely to sample, without making any commitment. 


Prelogon Facilities 


Some facilities should be available as prelogon facilities, so 
that any user can access them whether or not he has an account, 
directory, etc., at a given site. Some sites will not be able 
to support many of these functions, so a required set must be 
kept to a minimum. 


Remote User Facilitation 


Users not only need help with actual use of systems from a 
remote site, but they also need facilitation of administrative 
tasks. Station Agents should be able to handle most of these 
problems or transfer the user to the proper person. System 
access requirements, account and billing problems, and document 
acquisition need particular attention. 
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b. There should be a simple mechanism for users to acquire/update 
information in functional documents such as the Resource Note- 
book and in files such as identification files. Publications 
or files of this sort should combine the collective input of 
all the users. 


12. Transportability of Resources and Information 


a. Users should be able to easily transfer information, such as 
files, memos, mail, online documentation, (programs?!?) etc., 
from one site to another. 


13. Network Utilities 


a. Should distributed data banks and similar features be 
considered Network utilities that can be used by all? 


The idea of "Network Utilities" was recognized as an 
interesting one by the group, but there was little agreement as 
to what constitutes Network utilities or how they should be 
supported. 


CURRENT PLANS 


1. Neigus, Crocker, and Iseli will draft the scope, objectives, 
goals, and priorities of USING and will submit their 
recommendations for approval by the members. 


2. MITRE will design a New User’s Packet incorporating ideas from 
USING. 


3. Bowles, Hathaway, and Stoughton will write preliminary specs for a 
Network Common Command Language Protocol. All members should 
suggest a list of commands for consideration. 


4. Padlipsky will produce specifications for a simple, standard 
editor (NETED) which could easily be implemented by server hosts. 


5. A general Users Group (NIC ident = USERS) will be formed, to allow 
any interested person to monitor user-oriented activities, 
especially those of USING. Anyone interested in being in USERS 
should contact Dave Crocker (DHC). 
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Activities of the group will be reported in the ARPAnet News, and 
a user’s forum column will be made available for user’s comments. 


The group will meet again in the Fall of 1973 at the Network 
Information Center in Menlo Park, California. 


[ This RFC was put into machine readable form for entry ] 
[ into the online RFC archives by Via Genie 3/00 ] 
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